home *** CD-ROM | disk | FTP | other *** search
/ Atari Mega Archive 1 / Atari Mega Archive - Volume 1.iso / lists / mint / l_0799 / 628 < prev    next >
Encoding:
Internet Message Format  |  1994-08-27  |  4.9 KB
  1. From: Stephen Usher <Stephen.Usher@earth.ox.ac.uk>
  2. Subject: Re: include file problems
  3. Date: Wed, 10 Nov 1993 08:21:50 +0000 (GMT)
  4. In-Reply-To: <9311100418.AA18169@terminator.rs.itd.umich.edu> from "Nicholas S Castellano" at Nov 9, 93 11:18:25 pm
  5. Mime-Version: 1.0
  6.  
  7. >>Yes it would... to begin with at least. Once the major reorganisation had
  8. >>been done it would be far easier to maintain. It would also allow the
  9. >>complete merging of the TOS and MiNT libraries for all compilers into the
  10. >>one directory tree if it were a join task taken on by all the maintainers.
  11. >
  12. >It would be a pain in the beginning, and continuously.  I have enough
  13. >trouble as it is trying not to lose patches.
  14.  
  15. I understand this problem! :-)
  16.  
  17. >The merging of the various libraries is being worked on (or at least
  18. >Leif and I have been discussing how to merge the Lattice stuff into
  19. >the main distribution.)  Organizing the files into different
  20. >directories doesn't make this task any easier.
  21.  
  22. If it were done correctly it probably would, you might start being able to
  23. see the wood 'cos there'd be less trees.
  24.  
  25. A basic split would be:-
  26.  
  27.     startup code
  28.     compiler support
  29.     basic os (low-level) functionality
  30.     Unix/Posix compatability (built on top of the basic os part of the
  31.         library.
  32.     
  33. >>Much of the basic code doesn't change in the libraries... you'd be able to
  34. >>forget about those bits of code.
  35. >
  36. >Unfortunately this isn't true.  I wish it were.
  37.  
  38. Really? What about all the startup code, the GCC library stuff (all those
  39. annoying little source files for adding subtracting etc) I'm sure it would
  40. be a good idea to get those out of the way.
  41.  
  42. >>Also... you could farm out sub-sections of the libraries to subsiduary
  43. >>maintainers who could generate unified patches for those directories.
  44. >
  45. >...And then have a real headache when some change has to be
  46. >coordinated between seven different people.  Not to mention how
  47. >difficult it would be to get people to send patches to the correct person.
  48.  
  49. It would have to be thought out well, but I don't see it as being as bad as
  50. you paint it. As long as the divisions were logical and well defined you'd
  51. merely be a librarian gluing the sections together into the complete
  52. library and acting as a clearing house. If anything your job would be less
  53. taxing and less time consuming, you'd have less patches to apply, merely one
  54. from each sub-section every so often, which you'd pass onto the other groups
  55. so they could keep their libraries up to date.
  56.  
  57. >>At the moment C libraries for the Atari computers are a hotch-potch mess. We
  58. >>need to unify them and standardise asap IMHO so code will be able to be
  59. >>compiled using any of the compilers without hassle, at least the free-ware
  60. >>compilers. Maybe we could get the commercial compiler producers to get in
  61. >>line too.
  62. >
  63. >I agree.
  64.  
  65. At least there's something we agree upon! :-)
  66.  
  67. >>(By the way.... has anyone fixed scanf() yet? :-))
  68. >
  69. >I don't even know what's wrong with it, besides the fact that people
  70. >say it fails some tests.  Now if I could find those tests...
  71.  
  72. Hmm.. it's rather broken... I can hack it to pass the GNU tests but it still
  73. screws up big time when used in conjunction with yacc generated parsers and
  74. the like. I think we need a complete replacement, the current version is too
  75. broken to be economically fixable. Maybe we could use the one out of the GNU
  76. library or maybe the BSD one.
  77.  
  78. >>None other than it's a complete mess with everything just thrown into the
  79. >>same directory! We're going to have sub-directories for a whole lot of new
  80. >>stuff once the socket and other stuff is fully integrated.. ie. <un/*.h>,
  81. >><net/*.h>, <netinet/*.h>, <protocols/*.h> etc... oh and I forgot..
  82. >><posix/*.h>.
  83. >
  84. >The first four are all in the domain of the socket library, which is
  85. >not part of the mint library.  Maybe it will be at some point, i'll
  86. >worry about it then.
  87.  
  88. I think it's best to take a strategic view early so you don't go down a
  89. dangerous path which could lead to problems later.
  90.  
  91. >There is no posix/*.h.  All posix-required headers are in the main
  92. >include directory.  What would we gain by having posix/stdio.h,
  93. >posix/unistd.h etc.?
  94.  
  95. There are some parts of the POSIX definition which contradicts the ANSI
  96. definition.. this is why we may need suplimentry libraries and header files.
  97.  
  98. It all depends, of course, as to whether there will come a time when we need
  99. a number of versions of routines, one which is the "common" version and one
  100. which is POSIX complient. To use the POSIX version you'd include the posix
  101. headers and link with -lposix.
  102.  
  103. >--
  104. >entropy -- it's not just a good idea, it's the second law.
  105. >Personal mail:      entropy@gnu.ai.mit.edu
  106. >MiNT library mail:  entropy@terminator.rs.itd.umich.edu
  107.  
  108. Steve
  109.  
  110. -- 
  111. ---------------------------------------------------------------------------
  112. Computer Systems Administrator, Dept. of Earth Sciences, Oxford University.
  113. E-Mail: steve@uk.ac.ox.earth (JANET) steve@earth.ox.ac.uk (Internet).
  114. Tel:- Oxford (0865) 282110 (UK) or +44 865 282110 (International).
  115.